Flush stdout before slow stop in stop-all (fixes #256)#261
Merged
Conversation
The local/global `stop-all` handlers printed the in-progress
"Stopping '<name>'..." message with `print!` (no newline) and then ran
the graceful kill, which sleeps up to ~2.6s per server. With no newline,
line-buffered stdout held the text until the trailing `println!(" stopped")`
ran after the delay, so the whole line landed at once and looked frozen.
Flush stdout immediately after the `print!` so the prompt is visible
before the kill runs; " stopped" is then appended to the same line.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Actually, I think the issue is that it's waiting to collect the information about what's running, but doesn't emit any output to say so. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #256 —
chctl local server stop-all(and the global variant) showed no output for a few seconds, thenStopping 'default'... stoppedappeared all at once, making it look like the app had frozen.The two
stop-allhandlers inlocal/mod.rsprinted the in-progressStopping '<name>'...message withprint!(no trailing newline) and then ran the graceful kill, which sleeps up to ~2.6s per server (SIGTERM wait + optional SIGKILL wait). With no newline, Rust's line-buffered stdout held the text until the trailingprintln!(" stopped")ran after the delay — so the whole line landed at once.This flushes stdout immediately after the
print!so the prompt is visible before the kill runs. The final output text is unchanged (Stopping 'X'... stoppedon one line); only the timing changes —Stopping 'X'...now appears right away andstoppedis appended once the kill completes.The single-server
stopandstop_server_globalpaths already useprintln!(which flushes on the newline), so they were left unchanged.Testing
cargo buildandcargo clippyclean (no unused-import warning forWrite).--jsonoutput path is unchanged (still behind theif !jsonguard).🤖 Generated with Claude Code
Note
Low Risk
CLI-only UX timing change with no effect on kill logic, JSON output, or server lifecycle.
Overview
Fixes #256:
chctl local server stop-all(project-scoped and--global) looked frozen because theStopping '…'...line usedprint!without a newline and only appeared once the trailingstoppedran after ~2.6s graceful kill per server.Both
stop_all_servers_localandstop_all_servers_globalnow callstdout().flush()immediately after theprint!, so the in-progress text shows beforekill_server/kill_server_by_pid. Final line text is unchanged;--jsonpaths are untouched. Single-server stop paths already useprintln!and were not modified.Reviewed by Cursor Bugbot for commit b6543c0. Bugbot is set up for automated code reviews on this repo. Configure here.